1. Field of the Invention
The invention is related to the field of communication networks, and in particular, to implementing a message restriction process to control the transmission of messages from Diameter clients to Diameter servers.
2. Statement of the Problem
The Diameter protocol is defined by the IETF (Internet Engineering Task Force) as a base protocol intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility. The Diameter protocol has been used in 3GPP IMS standards for authentication, accounting, and policy management. A message in Diameter protocol includes, among other things, a version field, a message length field, a command flag field, a command code field, an application identifier field, and a plurality of Attribute Value Pairs (AVPs). There are a variety of AVPs that are defined by the IETF to provide a variety of functions.
In its most generalized form, a communication network implementing the Diameter protocol includes one or more Diameter clients that are being served by a Diameter server. A Diameter server receives Diameter Request messages from the Diameter clients, and responds to the clients with Diameter Response messages. For example, in an IMS network, a Diameter server may be represented by an Application Server (AS), a Policy Decision Function (PDF), a Resource Admission Control Subsystem (RACS), a AAA server, a Home Subscriber Server (HSS), a Charging Collector Function (CCF), a Charging Data Function (CDF), an Online Charging System (OCS), etc. A Diameter server could be one element, or multiple elements (a cluster). Any IMS network elements in an IMS network or other legacy or 2G networks may be Diameter clients which interface with the Diameter servers via Diameter protocol. A Diameter client may also be represented by a Diameter router implemented between IMS network elements and the Diameter servers.
The Diameter traffic flows in a communication network need to be controlled and balanced to guarantee system performance and reliability, including network element availability and geographical redundancy. Because a typical communication network includes a large number of Diameter servers and Diameter clients, it is presently a problem for the communication network to balance the load and traffic among the servers and clients. One traditional solution is to place load balance switches (LBS) in the communication network. The load balance switches monitor the traffic and load among all the Diameter servers, and attempt to distribute the traffic evenly among the servers. Unfortunately, the load balance switches can only distribute the traffic, but if the traffic volume is high, the Diameter servers may still get overloaded.
An overload condition in a Diameter server can cause significant problems in a communication network. When a Diameter client transmits a Diameter Request message to a Diameter server, the client sets a time interval during which the client expects to receive a Response message from the server. If the Diameter server is overloaded, then the server either will not respond to the Request message or will have a delayed response to the client. If the Diameter client does not receive a Response message within the time interval, then the Diameter client initiates a retry of the Request message. This process continues until the maximum number of retries in the client is reached. The process of having the client retry transmission of messages to the Diameter server can exacerbate the overload condition of the server by bombarding the server with even more messages.